--- title: "Laudo Oficial de Correção — Prova Teórica 1" subtitle: "Gestão de Projetos de Software (GPS) • CEFET-MG 2026.2" author: "Prof. Aléssio Miranda Júnior" date: "2026-10-19" discente: "Davi José do Nascimento" matricula: "20243001685" nota_final: "22,8" nota_maxima: "25,0" aproveitamento: "91,2%" legibilidade: "84% (Média - Grafite)" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm colorlinks: true --- ::: {.callout-note appearance="simple"} ## Dados do Discente - **Discente:** Davi José do Nascimento - **Matrícula:** `20243001685` - **Data da Avaliação:** 19/10/2026 - **Pontuação Final:** **22,8 / 25,0** (Aproveitamento: **91,2%**) - **Legibilidade da Caligrafia:** 84% (Média - Grafite) ::: ## Desempenho Consolidado por Questão | Questão / Tema | Pontos Obtidos | Valor | Aproveitamento | |:---|:---:|:---:|:---:| | **Q1:** Projeto, Ciclo de Vida e Trade-offs | **4,8** | 5,0 | 96,0% | | **Q2:** Escopo, EAP e Backlog | **4,6** | 5,0 | 92,0% | | **Q3:** Qualidade, CoQ e Definição de Pronto | **4,7** | 5,0 | 94,0% | | **Q4:** Riscos, Segurança de IA e Documentação | **4,5** | 5,0 | 90,0% | | **Q5:** Comunicação, Stakeholders e Conflitos | **4,2** | 5,0 | 84,0% | | **TOTAL GERAL** | **22,8** | **25,0** | **91,2%** | --- ## Questão 1 — Projeto, Ciclo de Vida e Trade-offs (4,8 / 5,0 pts) ### 1.1 Classificação como Projeto vs. Operação e Evidências (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "É um projeto. Após feito e devidamente configurado ele não requer mais um apoio constante durante seu tempo em uso, sendo assim um trabalho único com começo, meio e fim." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Classificação correta como Projeto , fundamentada no resultado único (trabalho único não contínuo) e temporalidade delimitada (começo, meio e fim). Pontuação integral: 1,5 / 1,5. ::: ### 1.2 Alternativas de Trade-off no Triângulo de Ferro (2,0 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Diminuir a quantidade de matérias que o assistente é capaz de ajudar: diminui o escopo mas não aumenta custo ou tempo. Aumentar o orçamento para tokens e modelos: aumenta o custo mas não diminui o escopo nem aumenta o tempo." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente! Articulou duas alternativas clássicas sem sacrificar a qualidade: (1) redução do escopo de matérias cobertas e (2) ampliação orçamentária/custos de infraestrutura para preservar cronograma e escopo. Pontuação integral: 2,0 / 2,0. ::: ### 1.3 Classificação do Ciclo de Vida (1,3 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "A abordagem é ágil, de forma que a cada 2 semanas um 'mini projeto' é entregue, podendo ou não ser dependente e ter relação com o anterior." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Classificou como ciclo Ágil destacando as entregas iterativas quinzenais em 'mini projetos'. Faltou apenas apontar a incerteza do modelo de IA como motivo impulsionador da flexibilidade ágil. Pontuação: 1,3 / 1,5. ::: --- ## Questão 2 — Escopo, EAP e Backlog (4,6 / 5,0 pts) ### 2.1 Estrutura Analítica do Projeto (EAP) e Regra dos 100% (1,3 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > [Diagrama: Nível 1: Interface do chat | Nível 2: geração de domínio, criação da tela, integração com backend] "A EAP assegura que uma funcionalidade seja dividida ao menor nível possível, formando uma hierarquia de complexidade aonde uma entrega mais acima depende diretamente das menores abaixo." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Construiu a hierarquia visual em 2 níveis definindo pacotes de trabalho concretos. Explicou a hierarquia funcional; faltou apenas formalizar o jargão da cobertura total e exclusiva da Regra dos 100%. Pontuação: 1,3 / 1,5. ::: ### 2.2 Detalhamento de Issues e Estimativa Relativa (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Issue 1.1.1: Geração de domínio | Descrição: Criar o domínio aonde a interface do chat ficará hospedada. | Critério de aceitação: Domínio online reservado e acessível. | Tempo estimado: 3 horas. Issue 1.1.2: Criação da tela | Tempo estimado: 40 horas. A segunda issue tem muito mais complexidade e nuances, tendo um tempo maior." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente formulação! Definiu a Issue 1 com todos os 4 campos canônicos e apresentou a Issue 2 comparativa justificando com clareza a disparidade de esforço e complexidade relativa. Pontuação integral: 1,5 / 1,5. ::: ### 2.3 Milestones vs. Sprints no Modelo Ágil / Kanban (1,8 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Milestones não substituem Sprints. Em um projeto pode se ter milestones definidos para entregas e prazos grandes e sprints menores, tudo em conjunto. Kanban sem sprint pode ser adotado em projetos de fluxo contínuo em que não possuam dependências entre as issues, onde uma atrasada impediria de fazer outra." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Muito lúcido! Demonstrou que milestones são agrupamentos macro de prazo/entrega que convivem com sprints e apontou acertadamente que Kanban sem sprints serve ao fluxo contínuo sob demanda. Pontuação: 1,8 / 2,0. ::: --- ## Questão 3 — Qualidade, CoQ e Definição de Pronto (4,7 / 5,0 pts) ### 3.1 Definição de Pronto (DoD) e Relação com CI/CD (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "DoD se refere ao parâmetro universal para todas as funcionalidades feitas, uma issue só é marcada como feita quando cumpre o DoD. No exemplo sem o teste de segurança o chat não pode ser marcado como feito pois para quem averiguar o projeto vai supor que os testes foram feitos, se baseando no DoD, gerando uma confusão e provável dívida técnica." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Resposta impecável! Definiu com maestria a universalidade do DoD e alertou com extrema perspicácia sobre o risco de gerar dívida técnica invisível caso testes de segurança sejam contornados. Pontuação integral: 1,5 / 1,5. ::: ### 3.2 Classificação PAF dos Custos da Qualidade (CoQ) (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "a. Prevenção | b. Avaliação | c. Falha externa | d. Falha interna O bug em produção (falha externa) tende a ser mais caro pois foi descoberto depois, gerando um efeito cascata grande para a resolução e causando perdas financeiras." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Perfeito! Mapeou 100% das 4 categorias de CoQ e justificou com clareza o efeito cascata e prejuízos operacionais da Falha Externa. Pontuação integral: 1,5 / 1,5. ::: ### 3.3 Heurística 1:10:100 e Particularidades de Projetos de IA (1,7 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "A regra do 1:10:100 diz que um problema descoberto no planejamento tem custo 1, pois ainda está no começo e não foi realmente feito nada comprometido, nos testes possui custo 10, pois apesar de ter perda de trabalho e necessidade de revisão ainda é apenas interno, e um erro descoberto em produção tem custo 100, pois além de demorado para corrigir ainda expõe o erro ao usuário final, podendo causar problemas financeiros, técnicos, de segurança entre outros. Por isso não podemos negar verificações em testes, pois é mais barato." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente explicação da progressão de custos nas fases de planejamento, verificação interna e produção. Faltou apenas apontar a limitação do não-determinismo na aplicação da heurística a modelos de IA. Pontuação: 1,7 / 2,0. ::: --- ## Questão 4 — Riscos, Segurança de IA e Documentação (4,5 / 5,0 pts) ### 4.1 Risco vs. Problema e Posicionamento na Matriz P×I (1,2 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Era um risco que virou um problema. Quando era só uma possibilidade era um risco, após ter um impacto vira um problema. A probabilidade era baixa, pois com certas camadas de segurança e experiência um desenvolvedor não faria isso, mas o impacto é crítico." [Matriz marcada no quadrante Impacto Alto × Probabilidade Baixa]. ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Diferenciou com exatidão risco de problema consumado. Posicionou corretamente no quadrante de Impacto Alto e Baixa Probabilidade. Faltou citar o nome formal da estratégia de resposta prévia (mitigação/prevenção). Pontuação: 1,2 / 1,5. ::: ### 4.2 Ações Imediatas e Prevenção Permanente de Chaves de API (1,25 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Retirada da chave e arquivos que possam possuí-la. Mudança de chave para outra não exposta. Contabilidade do custo gerado pelo vazamento com possível redução do orçamento do projeto para compensar. Verificação manual se arquivos como .env estão sendo commitados." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Ações imediatas de contenção excelentes (revogação, rotação e balanço orçamentário dos custos). Na prevenção permanente, sugeriu auditoria manual de arquivos .env, onde ferramentas automatizadas de secret detection e .gitignore configurado seriam mais robustas. Pontuação: 1,25 / 1,5. ::: ### 4.3 Modelagem de Riscos de IA e Artefatos de Documentação (ADRs) (2,0 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Prompt injection: Causa: usuário enviar comandos/instruções no prompt, (Probabilidade) alta, (Impacto) alto, (mitigação) verificação de saída, (contingência) banimento da conta. Alucinação pedagógica: Saída verificada e tratada antes de chegar ao usuário. ADR é o documento feito para guardar escolhas de arquitetura e segurança." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Brilhante! Modelou o risco de injeção de prompt com todos os campos requisitados, tratou o risco de alucinação na saída e recomendou com justificativa precisa o ADR (Architecture Decision Record) . Pontuação integral: 2,0 / 2,0. ::: --- ## Questão 5 — Comunicação, Stakeholders e Conflitos (4,2 / 5,0 pts) ### 5.1 Comunicação Síncrona vs. Assíncrona no GitLab (1,25 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Comunicação Síncrona: É em tempo real e permite uma duração estendida, mais humana, mas pode atrasar o desenvolvimento. Comunicação Assíncrona: Tempo maior de resposta, gera registros e histórico, menos humana mas consome menos tempo de desenvolvimento. Uma boa prática é fazer o misto dos dois. Reuniões via call com registro das decisões tomadas sendo enviada para todos os interessados e com atualizações assíncronas menores entre elas." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente reflexão sobre o equilíbrio entre contato humano e histórico registrado em atas e issues. Pontuação: 1,25 / 1,5. ::: ### 5.2 Matriz Poder × Interesse e Estratégia de Comunicação (1,3 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "O professor e a coordenação são quem possui maior poder sobre o projeto, podendo encerrá-lo ou exigir mudanças. Para o professor o melhor é possuir um canal de comunicação direta, via chat com atualizações e conversas frequentes sobre o andamento do projeto e funcionalidades, como o Telegram e e-mail." [Diagrama: (5) Manter satisfeito; (2) e (3) Gerenciar de perto; (4) Monitorar; (1) Manter informado] ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Posicionamento impecável dos 5 stakeholders nos 4 quadrantes da matriz. Estratégia de comunicação direta e frequente para o professor muito coerente. Pontuação: 1,3 / 1,5. ::: ### 5.3 Modos de Resolução de Conflito de Thomas-Kilmann (1,6 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Como ambas opiniões são contrárias não é possível seguir com as duas, sendo assim a melhor forma é um meio termo, buscando agradar as duas partes. Um exemplo seria um chat curto e socrático que pudesse oferecer respostas maiores dependendo da dificuldade do usuário, assim mantendo o objetivo de ensinar e evitando um custo exagerado por usuário. Respostas puramente longas por si só teriam um custo maior e poderiam incentivar alucinações e fugas de contexto, ao passo que respostas curtas podem não ser o suficiente para alunos com mais dificuldade." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Proposta sofisticada de conciliação / compromisso (meio-termo adaptativo). Justificou com precisão o porquê de cada postura extrema ser prejudicial. Faltou apenas nomear formalmente as posturas da grade de Thomas-Kilmann. Pontuação: 1,6 / 2,0. ::: --- *Laudo gerado oficialmente pela disciplina Gestão de Projetos de Software (GPS) • CEFET-MG Timóteo*